The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Increased use of distributed computer program applications, which run on multiple computer systems, has spurred the need for increased programmatic access among the systems. Numerous application programming interfaces (APIs) and new protocols have been developed that permit client applications running on client computer systems to make calls or other forms of programmatic requests to server application systems at other computers. A computer program initiating such a request to a remote server application system may do so independent of any request by an individual user of the computer program and thus may lack a user context for security authorization.
Many programmatic access APIs have been developed to utilize stateless protocols that have been traditionally used by individual users to access web applications. For example, programmatic interface protocols such as SOAP (Simple Object Protocol) or REST (REpresentational State Transfer) use HTTP (Hyper Text Transfer Protocol), which is traditionally used by client browsers under control of individual users to request and update data from a remote client system. HTTP is stateless so a server computer receiving an API call may have no security context or other security data with which to determine whether to accept and process the API call.
Authentication and authorization through a protocol such as HTTP have been closely tailored to the needs of individual users. Both the protocols, as well as the web server application servicing the protocol, have integrated authentication and authorization systems that are better suited for an individual user rather than a programmatic client. For example, individual user authentication and authorization usually involves an individual user selecting a particular user identifier to represent her identity and a particular password to be the secret shared only with the web application to be accessed. The user identifier is usually public and can be displayed by the web application's user interface or shared with other users (such as having the user identifier in a shared activity logs for records that are caused by the user). On the other hand, the user password is kept private and is a secret that cannot be shared under any circumstances.
Adapting the same access paradigm to a programmatic client application may not be efficient. A programmatic client, having no concern about the privacy, may not have a need to provide two different credentials, a user identifier and a password, for its access to a web application. Managing and maintaining extra credentials for each programmatic client may lead to wasteful use of resources, especially for a large number of programmatic clients, and creates a security vulnerability because the credential database could be attacked.
Additionally, the authorization scope of a server application system for an individual user may drastically differ from that of a programmatic client. An individual user may have authorization that is based on a role of the user. To minimize a number of authorization checks for each rendering of a user interface and processing input from the user interface, a particular role may be specified that covers all features of a web page user interfaces rendered by a web application. Thus, users that are granted the authorization of the particular role generally have full access to all the resources described on the web page. For example, a user with a “user administrator” role may have a full access to a web page that presents and configures all the resources related to user administration such as user accounts, user addresses, group affiliations and so on. But a programmatic client application that is used for an employee directory may only need authorization to retrieve first names and last names of users and their respective groups. Granting such a client application the “user administrator” role is unnecessary and perhaps, could expose the web application to a potential security breach as an employee directory application may not be as secure as the web application that manages users.